Secure digital content delivery system and method over a broadcast network

ABSTRACT

A system and a method for secure distribution of digital media content through a packet-based network such as the Internet. The security of the present invention does not require one-to-one key exchange, but rather enables keys, and/or information required in order to build the key, to be broadcast through the packet-based network. The digital media content is then also preferably broadcast, but cannot be accessed without the proper key. However, preferably only authorized end-user devices are able to access the digital media content, by receiving and/or being able to access the proper key. Thus, the present invention is useful for other types of networks in which digital media content is more easily broadcast rather than unicast, in addition to packet-based networks.

This application claims the benefit of U.S. Provisional Application No.60/206,140 filed on May 22, 2000.

FIELD OF THE INVENTION

The present invention relates to a system and a method for digitalcontent delivery, and in particular, to such a system and method inwhich the digital content is broadcast and/or multicast securely througha broadcast network, such as a packet-based network and/or IP network.

BACKGROUND OF THE INVENTION

Digital media content can easily and efficiently be delivered throughany type of suitable network, although typically such digital contenthas been delivered through cable and/or satellite networks as broadcastdigital content. However, in order for digital content to be fullyeffectively delivered to users, the basis for secure delivery needs tobe provided. In particular, if payment is required, the digital contentshould be secure against theft, such that only authorized users canretrieve and display the digital content. At the same time, the contentalso should be delivered in an efficient manner, for example by enablingthe secure delivery to be performed efficiently, without hindering orotherwise reducing the performance of the delivery mechanism itself,such as broadcast and/or multicast, for example.

One attempt to provide such effective mechanisms is described in U.S.Pat. Nos. 5,282,249 and 5,481,609, both to Cohen et al., which arehereby incorporated by reference as if fully set forth herein. Thedisclosed system enables a signal containing media content to bebroadcast widely, yet only to be played back or otherwise displayed byauthorized users. This signal could contain a television program forexample. The signal is scrambled, such that the authorized users areable to unscramble the signal and play back or otherwise display themedia content only with the proper security device, such as a smart cardfor example. Thus, widely received media content is still protected fromaccess by unauthorized users.

Scrambled television data streams described in the Cohen et al patentscomprise both scrambled data representing television signals and codedcontrol messages, also known as ECMs (Entitlement Control Messages). TheECMs of Cohen et al comprise, in a coded form, data necessary forgenerating a control word (CW) which may be used to descramble thescrambled data representing television signals. An ECM is also termed acontrol word packet or CWP.

Data necessary for generating a control word is known in the backgroundart to take many different forms and may include, in general, at leastany of the following: a control word; an encrypted control word packetwhich is intended to be decrypted before use; and a seed to a generatingfunction such as, for example, a one-way function which generates thecontrol word upon input of the seed. Throughout the presentspecification and claims the terms “control word generating information”and “CW generating information” are used interchangeably to designatedata necessary for generating a control word in any appropriate form, asdescribed above.

Another attempted solution is described in published European PatentApplication No. EP 0858184 and in corresponding U.S. Pat. No. 6,178,242,which disclose a digital recording protection system and which arehereby incorporated by reference as if fully set forth herein. Thedisclosed system enables the digital content to be sent in a digitallyscrambled format, such that the digital content cannot be read and/ordisplayed without a key. The key is obtained from a control message,which is only sent to authorized users. Preferably, the key is obtainedfrom coded information contained within the Entitlement Control Message,or ECM, for generating a control word associated with the ECM. Thus,only authorized users are able to correctly read and/or display thedigital content.

In addition, the system and method described in European PatentApplication No. EP 0858184 enable the authorized user to record andplayback or otherwise display the digital content, while preventing theuser from producing and distributing multiple playable copies of thedigital content to other, non-authorized users. Therefore, theauthorized user is able to fully use and enjoy the digital content,while the content itself is still protected from unauthorized use.

As described in European Patent Application No. EP 0858184, and as shownin background art FIG. 1 taken from this Application, such a systemincludes a media device 100, such as a television set, for playing thedigital content, such as a television program for example. Media device100 is connected to an integrated receiver-decoder (IRD) 110, forreceiving and decoding the digitally scrambled digital content. Thesystem also features a removable security element 120, such as a smartcard for example, for providing control words for unscrambling, orotherwise rendering into a clear format, the digitally scrambled digitalcontent by IRD 110. In addition, the system features a digital VCR 130for communicating with media device 100 and IRD 110 Digital VCR 130 isable to record the digital content for later playback and/or display bymedia device 100.

IRD 110 receives digitally scrambled digital content which features aplurality of ECMs, each of which is associated with, and is typicallyfollowed by, a digitally scrambled digital data segment, containing theactual digital content. Each ECM includes coded information which can beused to generate a control word for unscrambling the associateddigitally scrambled digital data segment. Typically, removable securityelement 120 generates the control word. IRD 110 is then able tounscramble the digitally scrambled digital content, for example forbeing played by media device 100.

Background art FIG. 2, also taken from European Patent Application No.EP 0858184, is a flow diagram illustrating the production of thedigitally scrambled digital content. As shown, the digitally scrambleddigital content is produced as an SDDS (digitally scrambled digital datastream) 140, featuring a plurality of ECMs such as an nth ECM 145, and aplurality of associated SDSEGs such as an nth SDSEG (digitally scrambleddigital data segment) 150 which is associated with nth ECM 145. IRD 110of FIG. 1, in cooperation with removable security element 120, is ableto use SDDS 140 in order to form a recording SDDS 165. Recording SDDS165 is produced with the addition of a TECM (transformed ECM) key, whichis permanently associated with the system of FIG. 1, even if removablesecurity element 120 is changed, replaced or exchanged, for example.This TECM key is used to make a plurality of TECMs, shown as nth TECM175, from the control words of the ECMs. Thus, a system which did notfeature the correct TECM key could not unscramble the recording SDDS 165for playing back or otherwise displaying the digital content, while theauthorized user is always able to play back or otherwise display therecorded digital content as long as the TECM key is available.

All of these background art references describe mechanisms for thesecure delivery of content which are quite useful for such networks ascable and/or satellite networks. However, these references are lessuseful for packet-based networks, such as the Internet for example, aswell as for other types of IP networks. Packet-based networks aretypically not dedicated networks for the delivery of particular types ofdigital media content. Certainly, many different types of content aredelivered through the Internet. Furthermore, the Internet is aninherently open, insecure conduit for digital content, as it is widelyaccessible. The general accessibility of the Internet is also quiteuseful, since digital media content could be delivered to many differentusers, internationally, easily and at relatively low cost.Unfortunately, the above-referenced background art references do notteach or suggest a mechanism for secure delivery of digital mediacontent through a packet-based network, particularly for selected,targeted digital media content.

Furthermore, encryption for media content which is transmitted accordingto such formats and standards as MPEG (Motion Picture Expert Group) ishandled at the PID level, such that only 13 bits of information areprovided, and such that decryption and re-encryption of the data wouldbe required when transmitted across networks. Such a small amount ofinformation is not sufficient for both encrypting the digital mediacontent and for identifying those devices which are permitted to decryptand access the content. The further requirement forencryption/decryption when crossing networks is also a disadvantage,since encryption of data which is transmitted according to IP protocolsprovides an “end-to-end” solution, such that the encrypted data istransmitted in its encrypted format to the end device or client. Bycontrast, PID is a data link protocol only, and as such, any encrypteddata which is transmitted must be decrypted and re-encrypted at eachsegment of the transmission path, such that the encrypted data cannot betransmitted directly to the end device or client in its encryptedformat.

Currently, security for the transmission of content over packet-basednetworks is handled through one-to-one key exchange mechanisms, in whicha central server sends a key individually to each end user computer.Clearly, sending such a key separately to each such computer isinefficient, as it requires extensive bandwidth. Furthermore, themanagement of such keys is also difficult, although a number ofattempted solutions have been proposed.

For example, IPSEC (Internet security framework) was initially developedas a framework for unicast protocols, which was also intended for usefor multicast transmission as an additional feature (but which was notspecifically designed for multicast transmissions). However, some of theelements that can be useful in a unicast environment become problematicwhen extended to multicast situations. A case in point is key basedsecurity systems and their required infrastructure.

There are two main areas for classic key management in a multicastenvironment: initializing a multicast group with a common key andrekeying (or updating) the multicast group. For example, public keysystems require a mechanism for obtaining the public keys necessary. Aserver and request model per session is notably insecure, e.g. imposter,man-in-the-middle, etc. If a client-server model is to be used, thenthird party authentication and certification is also necessary, forexample according to the X.509 standard. This standard allows forcertification hierarchy, and traversal of trusted paths; however, it isa slow and traffic heavy distribution method.

Cryptographic techniques have been proposed in order to increase thesecurity of key distribution, by encrypting the keys before they aresent. Unfortunately, a basic problem with using cryptographic techniquesfor key distribution is that each user must be authenticated to receivea key.

In general, standard group key management schemes establish and manage acommon key for all members of a group. These management schemes are usedfor encryption standards and group authentication. A particular problemin this area is related to key revocation methods, as these models tendto work with largely static key possession, since updating with thedistribution methods available tends to be bandwidth expensive and timeconsuming. Examples of key management protocols are described withregard to United Kingdom Patent No. GB 2353682 and U.S. patentapplication Ser. No. 09/502,867, both of which are hereby incorporatedby reference as if fully set forth herein.

One example of a significant Group Key Management proposal is the GKMPprotocol, which uses symmetric keys for all members of the group. Thismechanism features a dedicated Group Controller (GC) whoseresponsibility is managing the group keys. The GC generates group keysin a joint operation with a selected group member. It then communicateswith each member separately, validating permissions and sending it agroup key, which is encrypted using a shared key (between that memberand the GC). This method has very obvious and severe scalingdifficulties.

The Scalable Multicast Key Distribution protocol uses Core-Based Treerouting protocol and provides a secure join to a group tree in ascalable method. In such a tree, the routers know the identities oftheir tree neighbors, and starting from the core which serves as a GC(for generating group session keys and key distribution keys) andworking outwards, each router is delegated the ability to authenticatejoining members and provide them with the group key. This method isscalable, however it is tied to a specific routing protocol, andcombines routing with security, such that each router must be fullytrusted since it has the same keys as the GC.

In MKMP (Multicast Key Management Protocol), the initial Group KeyManager (GKM) delegates key distribution authority dynamically. The GKMgenerates a group key and then sends a multicast message solicitingmembers to whom it can delegate the distribution authority for the restof the group members. A message containing keys and access lists is sentto and decrypted by those solicited members, who will then operate asGKMs in their own right. This method allows for a dynamic adaptableon-line group topology. Since MKMP uses a single key for the total groupit avoids multiple (hop-by-hop) decryption/re-encryption of payload.

Lolus deals with scalability issues by using a “secure distributiontree”, wherein the multicast group is divided into a hierarchical set ofsubgroups. There is a Group Security Controller (GSC) at the top leveland Group Security Intermediaries (GSIs) for managing the subgroups.Each subgroup has its own sub-key, chosen by the GSI. The GSI knows thekeys to the subgroup and the next higher group and translates messagesbetween the levels. This models suffers from built in latency, duringdecryption and re-encryption and has difficulties dealing with untrustedGSIs.

In general, GKMP systems which rely on a single group controller stillhave difficulty scaling to large systems and are burdened by the ‘singlepoint of failure’ attribute. Single point of failure in this instancealso reflects in the security realm. Where, in some of the models above,more than one GC is used, the compromise of one such GC usually means acompromise of the other GCs as well. Furthermore, all of these protocolssuffer from drawbacks in the area of compromise recovery and/orrevocations of membership.

Various methods have been discussed in the literature in order toimprove group key management systems, for example by using groups ofmembers as controllers and cluster architectures. Hardjono, et al(“Secure IP Multicast: Problem areas, Framework, and Building Blocks”,Internet Research Task Force, draft-irtf-smug-framework-01.txt September2000; for other references, see the list at the end of this section)suggest a further extension of the Lolus tree distribution model, andother extensions/proposed solutions have also been suggested.

In ‘Key management for Multicast: Issues and Architecture’ (see fullreference below), a hierarchical tree approach is proposed in orderlimit the number of transmissions (key exchanges) and storage (of keys)required. Although more efficient than other variations, the basic keydistribution principles are still enforced and are still subject to thesame arguments previously cited against standard key distributionmodels.

The above problems become even more complex with regard to keyrevocation. In order to prevent new group members from accessing olderdata or leaving members from accessing new data, a group controller hasto change the multicast group key whenever membership in the groupchanges. Adding a new member either from a central GC or from one of thedistributed models is fairly straight forward and efficient, i.e. usinga one to one unicast model. However revoking membership rights in thestandard group key protocols becomes very problematic, because theleaving member already has the group key.

The approach taken by many key management protocols (GKMPA, SMKD, MKMP)to remove members is to generate a new group key, and to send itindependently to each of the remaining group members, usually usingsecret keys which are shared between each of the members and the GC. Inthis scenario, a new multicast group is created. But the scalingproblems here are significant, as are the timing issues, i.e. how tomake the new key available in time to access the new data, and how tomanage cases where it does not. In particular, the group is notoperational during the recovery process once the old key has beendeclared to be invalid, such that recovery/revocation processes areinefficient and may even prevent the legitimate members from receivingdata and/or other services. Timing issues are less significant for theinitial creation of the group, since members may be selected and mayreceive the key(s) well in advance of the actual operation of the group.

The alternatives discussed above where groups are divided into varioussub-groups, be they trees, hierarchical trees, clusters, etc allow forbetter scaling by simply requiring changes within the affected subgroup.It does become more complex when one of the local controllers for agroup becomes untrusted, since replacement keys must be handled within acomplex structure, and between different levels of influence.

Various other mechanisms are defined in the literature to overcome theseproblems, including using sets and subsets of keys distributed amongstthe group members, multiple keys distributed in such a fashion that eachmember cannot compute a new key value on its own, but rather requiresactive participation of the other members, etc. None of these mechanismsovercome the previously described problems which are inherent to suchkey distribution mechanisms.

REFERENCES

-   1. Vicki Johnson and Marjory Johnson—IP Multicast Initiative (IPMI)    White Papers—Stardust.com Inc. www.ipmulticast.com-   2. T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore “Secure IP    Multicast: Problem areas, Framework, and Building Blocks”, Internet    Research Task Force, draft-irtf-smug-framework-0.1.txt September    2000.-   3. T. Hardjono, R. Cain, N. Doraswamy “a Framework for Group Key    Management for Multicast Security”, Internet Engineering Task Force,    drafi-ietf-ipsec-gkmframework-03.txt August 2000.-   4. D Wallner, E. Harder, R. Agee—Key Management for Multicast:    Issues and Architectures, National Security Agency June 1999.    Network Working Group—Request for Comments: 2627. Copyright The    Internet Society 1999.-   5. Harney, H., Muckenhirn, C. and T. Rivers, “Group Key Management    Protocol (GKMP) Architecture”, RFC 2094 September 1994.-   6. Harney, H., Muckenhirn, C. and T. Rivers, “Group Key Management    Protocol Specification”, RFC 2093 September 1994.-   7. H. Harney, A. Colegrove, E. Harder, U. Meth, R. Fleisher, “Group    Secure Association Key Management Protocol”, INTERNET-DRAFT,    draft-harney-sparta-gsakmp-sec-02.txt, June 2000.-   8. Ballardie, T. “Scalable Multicast Key Distribution”, RFC 1949 May    1996.-   9. R. Canetti, B. Pinkas “A Taxonomy of Multicast Security Issues”    draft-irtf-smug-taxonomy-01.txt August 2000.-   10. O. Rodeh, K. Birman, D. Dolev “Optimized Group Rekey for Group    Communication systems”,    http://www.cs.huji.cs.huji.ac.il˜orodeh/papers/opt/main.html.-   11. Bellovin, S. M. “Problem Areas for the IP Security Protocols”    Proceedings of the Sixth USENIX UNIX Security Symposium San Jose    Calif., July 1996.-   12. S. Frankel, S. Kelly, R. Glenn, “The AES Cipher Algorithm and    Its Use With Ipsec” Ipsec Working Group,    draft-ietf-ipsec-ciph-aes-cbc-01.txt November 2000.-   13. S. Kent, R. Atkinson “IP Encapsulating Security Payload (ESP)”,    Network Working Group Request for Comments: 2406 November 1998.-   14. S. Kent, R. Atkinson “Security Architecture for the Internet    Protocol”, Network Working Group Request for Comments: 2401 November    1998.-   15. R. Canetti, et al “An Architecture for Secure Internet    Multicast”, draft-ietf-ipsec-sec-mcast-arch-00.txt. No date given.-   16. Rogaway, P. “Problems with Proposed IP Cryptography”, Comments    draft-rogaway-ipsec-comments-00.txt, Apr. 3, 1995.-   17. Mittra, S. “Lolus: A Framework for Scalable Secure Multicasting”    Proceedings of the ACM SIGCOMM 1997.-   18. Ming, D. “Techniques for multicast key update” Email message    received on Smug Mail List, Mar. 31, 2000.-   19. U.S. Pat. No. 5,282,249: System for controlling access to    broadcast transmissions, M. Cohen, J. Hashkes, Jan. 25, 1994.-   20. U.S. Pat. No. 5,420,866: Methods for providing conditional    access information to decoders in a packet-based multiplexed    communications system, A. J. Wasilewski, Scientific_Atlanta, Inc,    May 30, 1995.-   21. U.S. Pat. No. 5,481,609: System for controlling access to    broadcast transmissions, M. Cohen, J. Hashkes, News Data Security    Products Ltd. Jan. 2, 1996.-   22. U.S. Pat. No. 6,049,878: Efficient, secure multicasting with    global knowledge, G. Caronni, M. Waldvogal, Sun Microsystems Apr.    11, 2000.-   22. U.S. Pat. No. 6,195,751: Efficient, secure multicasting with    minimal knowledge, G. Caronni, M. Waldvogal, Sun Microsystems Feb.    27, 2001.-   23. U.S. Pat. No. 6,108,706: Transmission announcement system and    method for announcing upcoming data transmissions over a broadcast    network, K. J. Birdwell, et al, Microsoft Corporation, Aug. 22,    2000.-   24. U.S. Pat. No. 6,002,768: Distributed registration and key    distribution system and method, A. Albanese, R. Oppliger,    International Computer Science Institute, Berkeley, Calif., Dec. 14,    1999.-   25. U.S. Pat. No. 5,784,463: Token distribution, registration, and    dynamic configuration of user entitlement for an application level    security system and methods, J. F. Chen, J Wang, V-ONE Corporation.    Jul. 21, 1998.-   26. U.S. Pat. No. 6,061,791: Initial secret key establishment    including facilities for verification of identity, T. Moreau,    Connotech Ecperts-Conseils Inc. May 9, 2000.-   27. U.S. Pat. No. 4,868,866: Broadcast data distribution    system, B. L. Williams Jr., McGraw-Hill, Sep. 19, 1989.-   28. U.S. Pat. No. 5,761,306: Key replacement in a public key    cryptosystem, T. Lewis, Visa International Service Association, Jun.    2, 1998.-   29. U.S. Pat. No. 5,748,736: System and method for secure group    communications via multicast or broadcast, S. Mittra, May 5, 1998.-   30. U.S. Pat. No. 6,026,167. Method and apparatus for sending secure    datagram multicasts, A. Aziz, Sun Microsystems Inc. Feb. 15, 2000.-   31. U.S. Pat. No. 5,029,208: Cipher-key distribution system, K.    Tanaka, NEC Corporation, Jul. 2, 1991.-   32. U.S. Pat. No. 5,778,187: Multicasting method and apparatus, A.    Monteiro, J. F. Butterworth, Netcast Communications Corp, Jul. 7,    1998.-   33. A. Kleinmann, “Scenarios and Requirements for Business-Oriented    Multicast Security”, Secure Multicast Research Group, Meetings, Dec.    7, 1998.

The disclosures of all references mentioned above and throughout thepresent specification are hereby incorporated herein by reference.

SUMMARY OF THE INVENTION

None of the disclosed background art solutions provides a securitysystem for the delivery of targeted digital media content through apacket-based network such as the Internet. Furthermore, none of thereferences teaches or discloses a mechanism for providing such asecurity system without requiring one-to-one key exchange, while stillenabling selection of specific digital media content by particular endusers. In addition, none of the references teaches or suggests amechanism for broadcasting digital media content in a secure manner to ageneral group of end users, while still maintaining the desired degreeof specificity in terms of those end users who actually use or accessthe digital media content. Also, none of the references teaches orsuggests a mechanism for broadcasting and/or multicasting which isitself both efficient and secure, such that the security mechanisms donot detract from the performance of the actual delivery mechanism.

Therefore, there is an unmet need for, and it would be highly useful tohave, a system and a method for secure digital content delivery, whichenables digital media content to be delivered through a packet-basednetwork such as the Internet, without requiring any inherent security inthe provisions of the network itself, and without requiring one-to-onekey exchange.

The present invention, in preferred embodiments thereof, fulfills theseneeds by providing a system and a method for secure distribution ofdigital media content through a broadcast network, which may be apacket-based network such as the Internet and/or any type of IP network(even for those IP networks which are not packet-based networks).However, for the purposes of discussion only, the following descriptioncenters around packet-based networks, and more specifically IP networkswhich are packet-based networks, such as the Internet for example. Inaddition, the present invention is particularly concerned with broadcastand/or multicast transmissions through such networks.

The security of the present invention does not require one-to-one keyexchange, but rather enables keys, and/or information required in orderto build the key, to be broadcast through the network. The digital mediacontent is then also preferably broadcast, but cannot be accessedwithout the proper key. However, preferably only authorized end-userdevices are able to access the digital media content, by receivingand/or being able to access the proper key. Thus, the present inventionis useful for other types of networks in which digital media content ismore easily broadcast rather than unicast, in addition to packet-basednetworks.

The present invention, in preferred embodiments thereof, supports thedistribution of content to end user devices from one or more centraldistribution points, as in client-server models and variations thereof,and/or peer-to-peer distribution, for example between end user devices.In addition, the present invention, in preferred embodiments thereof,also supports distribution models within either of these mechanisms forunitary distribution, to a specified end user device, orbroadcast/multicast distribution, to a plurality of end user devices. Inany case, in order for the distributed content to be operative, forexample to be “played back” or otherwise displayed, the recipient enduser device is optionally and more preferably in communication with abroadcaster at least once before such a display is permitted. Thebroadcaster then enables the recipient end user device to play back orotherwise display the received content, for example by sending a code tothe recipient end user device. Optionally, the broadcaster may requirepayment to be received before enabling the content for the recipient enduser device. Thus, the present invention supports flexible distributionof content according to a number of different distribution models, whilestill preventing unauthorized play back or other display.

According to preferred embodiments of the present invention, there isprovided a combination of secure hardware and software to prevent and/orat least retard unauthorized access or “hacking”. In order for access tothe distributed content to be controlled, the content itself must beprotected, for example by encryption or scrambling. Hereinafter, theterm “scrambling” is considered to encompass both encryption, whichinvolves the mathematically determined alteration of content or evenonly a part thereof to a form which cannot be read without the properkey, and a simpler form of scrambling, which involves the rearrangementof portions of the content, such that the content is only readable whenproperly rearranged. Indeed, even the simpler forms of scrambling can beeffectively performed by altering, or otherwise rendering inaccessible,a small percentage of the overall content, after which the entire unitof content can no longer be displayed. By protecting the content itself,the present invention enables the content to be completely portable, andto be distributed freely, while still ensuring that control of access tothe content is maintained by a central authority as required.

The preferred combination of hardware and software components enablesthe present invention to most effectively protect access to the content,while still enabling the user to easily and transparently play back, orotherwise display, the content. More preferably, the end user devicewhich is used for the present invention includes a security module, forunscrambling the digitally scrambled content according to a receivedcode. The security module optionally and more preferably features arenewable security submodule, such as a smart card with a smart cardreader for example, although of course any suitable combination ofsoftware and/or hardware may optionally be used. The security modulereceives the necessary code from the broadcaster, and is then able tounscramble the received content for play back or other display. Mostpreferably, the operation of the security module is transparent orsubstantially transparent to the end user.

According to the present invention, there is provided a method forcreating a secure transmission mechanism for a plurality of end userdevices in a packet-based network, comprising: providing a plurality ofpackets; securing the plurality of packets according to securityinformation to form secured packets; transmitting the securityinformation to more than one end user device simultaneously through thepacket-based network; and multi-casting the secured packets to theplurality of end user devices.

According to another embodiment of the present invention, there isprovided a method for producing a conditional access (CA) system for usein a packet-switched environment (packet CA system) from a CA system foruse in a broadcast environment (broadcast CA system), the methodcomprising: providing a broadcast CA system comprising at least one CAsecurity characteristic; providing a packet-switched data transmissionsystem including a security subsystem having a plurality ofpacket-switched security characteristics; and creating a mapping fromthe at least one CA security element to at least one of the plurality ofpacket-switched security elements, thereby producing a packet CA system.

According to yet another embodiment of the present invention, there isprovided a packet-switched conditional access (CA) system for use withan end-user playback device, the CA system comprising: a protected datareceiver for receiving protected data protected with at least one key;an ECM packet receiver for receiving at least one ECM packet from apacket-switching network; and an ECM-based key generator for generatingthe at least one key from the at least one ECM packet.

According to still another embodiment of the present invention, there isprovided a method for providing an entitlement control message (ECM)based conditional access (CA) system based on a packet-switching networkcomprising: receiving a plurality of ECMs via the packet-switchingnetwork; storing the plurality of received ECMs; and choosing, fromamong the plurality of stored ECMs, an ECM for providing access toCA-protected data.

According to yet another embodiment of the present invention, there isprovided a method for creating a secure transmission mechanism for aplurality of end user devices in a packet-based network, comprising:encrypting a plurality of packets with a key to form encrypted packets,the key having associated key information for determining the key;multi-casting the associated key information to the plurality of enduser devices through the packet-based network, thereby obviating theneed to send the associated key information to each end user deviceindividually; and multi-casting the encrypted packets to the pluralityof end user devices to form the secure transmission mechanism.

According to still another embodiment of the present invention, there isprovided a method for creating a secure transmission mechanism for aplurality of end user devices in a packet-based network, comprising:multi-casting a plurality of secured packets and security information tothe plurality of end user devices, thereby obviating the need for aone-to-one transmission of the security information to each end userdevice individually and thereby forming the secure transmissionmechanism.

Hereinafter, the terms “file”, “portion”, “item” or “stream”, withregard to digital content, are used interchangeably and refer to anyunit of data for such digital content, whether as a functional unit suchas a packet for example, or as a conceptual unit such as a televisionprogram for example. “Streamed” or “streaming” data may also beconsidered as being formed from any type of unit of data.

Hereinafter, the term “display” refers to any type of playback orplaying out of media content data for a user, or otherwise renderingsuch data sensible to one or more human senses, including, but notlimited to, the audible production of audio data and the visibleproduction of video data, and combinations thereof.

Hereinafter, the term “network” refers to a connection between any twoor more computational or other electronic devices which permits thetransmission of data.

Hereinafter, the term “computational device” includes any type ofdigital instrument which is capable of operating a software program.

For the present invention, a software application could be written insubstantially any suitable programming language, which could easily beselected by one of ordinary skill in the art. The programming languagechosen should be compatible with the computational device according towhich the software application is executed. Examples of suitableprogramming languages include, but are not limited to, C, C++, Java andAssembly.

In addition, the present invention could be implemented as software,firmware or hardware, or as a combination thereof. For any of theseimplementations, the functional steps performed by the method could bedescribed as a plurality of instructions performed by a data processor.

Hereinafter, “Applied Cryptography” by Bruce Schneier, John Wiley 2nded. 1996, is incorporated by reference as if fully set forth herein, forthe teachings regarding cryptography and techniques for implementationthereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is herein described, by way of example only, withreference to the accompanying drawings, wherein:

FIG. 1 is a schematic block diagram of a background art system;

FIG. 2 shows a flow diagram illustrating the production of the digitallyscrambled digital content according to the background art;

FIG. 3 is a schematic block diagram of a system according to the presentinvention for secure delivery of digital content through a packet-basednetwork;

FIG. 4 shows an exemplary format of an encrypted media content packetaccording to the present invention;

FIG. 5 shows an exemplary format for ECM packets according to thepresent invention;

FIG. 6 shows an exemplary EMM packet according to the present invention;

FIG. 7 shows an exemplary but preferred implementation of thebroadcaster headend of FIG. 3 in greater detail according to the presentinvention; and

FIG. 8 shows an exemplary but preferred implementation of the end-userclient of FIG. 3 in greater detail according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention features a system and a method for securedistribution of digital media content through a packet-based networksuch as the Internet, or another type of IP network, throughmulticasting and/or broadcasting of data. The security of the presentinvention does not require one-to-one key exchange, but rather enableskeys, and/or information required in order to build the key, to bebroadcast through the packet-based network. The digital media content isthen also preferably broadcast, but cannot be accessed without theproper key. However, preferably only authorized end-user devices areable to access the digital media content, by receiving and/or being ableto access the proper key. Thus, the present invention is useful forother types of networks in which digital media content is more easilybroadcast rather than unicast, in addition to packet-based networksand/or various types of IP networks.

The present invention supports the distribution of content to end userdevices from one or more central distribution points, as inclient-server models and variations thereof, and/or peer-to-peerdistribution, for example between end user devices. In addition, thepresent invention also supports distribution models within either ofthese mechanisms for unitary distribution, to a specified end userdevice, or broadcast/multicast distribution, to a plurality of end userdevices. However, for the purposes of the present invention,distribution by broadcast and/or multicast is considered to beparticularly preferred. In any case, in order for the distributedcontent to be operative, for example to be “played back” or otherwisedisplayed, the recipient end user device must have been in communicationwith a broadcaster at least once before such a display is permitted. Thebroadcaster then enables the recipient end user device to play back orotherwise display the received content, for example by sending a code tothe recipient end user device. Optionally, the broadcaster may requirepayment to be received before enabling the content for the recipient enduser device. Thus, the present invention supports flexible distributionof content according to a number of different distribution models, whilestill preventing unauthorized play back or other display.

According to a preferred embodiment of the present invention, thedigital media content is securely transmitted through an IP network asthe packet-based network (although non-packet based IP networks and/ornon-IP but packet-based networks are also optionally implemented withthe present invention). Optionally, the IP network is the Internet.However, transmission of such digital media content may be differentthan transmission of other types of data through a network such as theInternet. For example, a typical Internet-based content provider doesnot have a continuous or at least continuing relationship with the enduser, but instead may only supply such content on a “one-off” orone-time basis.

By contrast, a broadcaster of digital media content through an IPnetwork may optionally wish to require a subscription or repeatedpayments for repeated accesses to the digital media content, althoughalternatively, the security information may optionally be “hard-wired”into the end user receiving device. Also, payment is more likely to beregular and repeated, rather than a single individual payment.Therefore, broadcasters of content through an IP network need be able tohandle many end users in a secure, scalable manner. As previouslydescribed, one-to-one key exchanges are clearly not a reasonable,efficient, scalable mechanism for such security.

The environment of IP networks such as the Internet is also based upon aparticular group of standards, which define the protocols forcommunication through such a network, and which are different from thecommunication protocols and standards for transmission through adedicated cable network, for example. These protocols must be used forcommunication through the network. Thus, the present invention ispreferably constructed with agreed standards and protocols, of which anexample is given below for an IP network, it being understood that thepresent invention is operative with substantially any type ofpacket-based network.

Security for IP networks is currently based upon the IPSEC (Internetsecurity framework) for creating the related set of standards, which areintended to provide a security protocol in the network layer as part ofthe network structure. The IPSEC standards assume but do not requirethat security is based upon key exchange protocols. These standards donot consider multicast scalability issues, particularly with regard tokey exchange and management issues for large numbers of simultaneoususers. However, the present invention is preferably compatible with theIPSEC standards, while differing in the actual application of thesecurity protocol itself, for example by associating the media contentstream with the matching ECMs (entitlement control messages) accordingto the IPSEC announcement protocol. More preferably, at least certainIPSEC mechanisms are used for coordinating the delivery of securityinformation such as ECMs to the end user devices, in order to ensurecompatibility between the system of the present invention and othersystems.

According to preferred embodiments of the present invention, there isprovided a combination of secure hardware and software to prevent and/orat least retard unauthorized access or “hacking”. In order for access tothe distributed content to be controlled, the content itself must beprotected, for example by encryption or scrambling. Hereinafter, theterm “scrambling” is considered to encompass both encryption, whichinvolves the mathematically determined alteration of content or evenonly a part thereof to a form which cannot be read without the properkey, and a simpler form of scrambling, which involves the rearrangementof portions of the content, such that the content is only readable whenproperly rearranged. Indeed, even the simpler forms of scrambling can beeffectively performed by altering, or otherwise rendering inaccessible,a small percentage of the overall content, after which the entire unitof content can no longer be displayed. By protecting the content itself,the present invention enables the content to be completely portable, andto be distributed freely, while still ensuring that control of access tothe content is maintained by a central authority.

The preferred combination of hardware and software components enablesthe present invention to most effectively protect access to the content,while still enabling the user to easily and transparently play back, orotherwise display, the content. More preferably, the end user devicewhich is used for the present invention includes a security module, forunscrambling the digitally scrambled content according to a receivedcode. The security module optionally and more preferably features arenewable security submodule, such as a smart card and smart card readerfor example, although any combination of hardware and/or software mayoptionally be used. The security module receives the necessary code fromthe broadcaster, and is then able to unscramble the received content forplay back or other display. Most preferably, the operation of thesecurity module is transparent or substantially transparent to the enduser.

The principles and operation of the present invention may be betterunderstood with reference to the drawings and the accompanyingdescription.

Referring, now to the drawings, FIG. 3 is a schematic block diagram ofan illustrative system according to the present invention for securedelivery of digital media content through a packet-based network as anexemplary but preferred implementation of the present invention, aspreviously described.

As shown, a system 200 features an end user device 210 with anassociated security module 220. Security module 220 optionally andpreferably comprises a smart card, such that end user device 210 (orsecurity module 220) would also feature a smart card reader, although ofcourse other implementations are possible. For example, security module220 could optionally be implemented as software alone, or as acombination of hardware and software. For the purposes of descriptionbelow only and without any intention of being limiting in any way,security module 220 is assumed to include a smart card reader and smartcard.

End user device 210 also features a media player 230 for playing back orotherwise displaying at least one type of media content, such as audiocontent for example. End user device 210 operates an end-user client240, which acts as the interface between end user device 210 and abroadcaster headend 250. End user device 210 and broadcaster headend 250communicate through at least one channel 205. Two such channels 205 areshown, although optionally system 200 could feature more channels 205,or alternatively could feature only one channel 205. At least onechannel 205 is preferably a network, which could be substantially anytype of suitable network, including but not limited to, the Internet, acable network or a satellite distribution mechanism. Optionally but morepreferably, as described in greater detail below, such a channel 205 isan IP network, such that communication between end user device 210 andbroadcaster headend 250 is in the form of an IP session. However, theterm “channel” itself may refer to any type of mechanism for datatransmission, regardless of the type of data and/or the transmissionmedium.

Broadcaster headend 250 in turn communicates with broadcaster 280 inorder to provide at least the security information to end user device210 through end-user client 240.

More preferably, only security features are provided to end user device210 through end-user client 240, and the actual content is transmittedseparately. Optionally and more preferably, the actual media content istransmitted from a broadcaster content interface 290 to a client contentinterface 270, through a same or different channel 205 as the associatedsecurity information, such that the security information is notnecessarily transmitted with the secured content. Client contentinterface 270 then passes the media content to media player 230, aftersuch media content has been accessed with the necessary securityinformation. Optionally and most preferably, each of client contentinterface 270 and broadcaster content interface 290 has access to aparticular database for storing the security information, shown in FIG.3 as a client database 260 and a broadcaster database 295 respectively.Each of client database 260 and broadcaster database 295 is preferablysecured with some type of security mechanism.

The security features for the content are preferably provided byencrypting the content, such that access to the media content is onlypossible for authorized users, although optionally contact withbroadcaster 280 and/or broadcaster headend 250 is not required. However,rather than using one-to-one key exchange, which would be veryinefficient as it would require specific transmission of the key to eachend user device 210, preferably access information is broadcast ormulticast to a plurality of end user devices 210. This information couldbe sent in the form of a particular message through channel 205, inwhich case the information would be a permission message. The presenceor absence of information which is locally accessible by each end userdevice 210 then determines whether the broadcast or multicast accessinformation is actually usable by a particular end user device 210, morepreferably in order to create a key which is then used to access themedia content by security module 220. Optionally, if a plurality ofdifferent broadcasters 280 are present, separate storage space forcredit information and/or other broadcast information is preferablyprovided on said security module 220 for each broadcaster 280.

According to a particularly preferred embodiment of the presentinvention, the access information is preferably distributed through anECM (control message), which more preferably enables end user device 210to create the correct key and as such may be considered to be an exampleof a permission message. For example, the ECM could comprise a seedwhich is input into a function performed by security module 220, theresult of which is the key required to access the media content, bydecrypting the media content or otherwise rendering the media contentinto a displayable format.

Optionally, the ECM is broadcast to all end user devices 210, but theparticular end user device 210 is more preferably only able to generatethe key if this end user device 210 also receives an EMM, or entitlementmessage, from broadcaster headend 250. The EMM is optionally and morepreferably used for periodic renewal of security module 220, such thatwithout periodic receipt of such an EMM, security module 220 eventuallyis no longer able to access the media content, since security module 220is no longer able to use the ECM information to generate the key fordecrypting or otherwise accessing the media content. More preferably,each EMM contains one or more content service identifiers, which may bean alphanumeric string for example. Although the term “serviceidentifier” is used herein, it should be noted that in face suchidentifiers may optionally refer to any type of authorization, and notonly authorizations for services. At least one such identifier is alsopresent in the ECM, such that security module 220 is more preferablyonly able to access those ECMs for which a matching service identifierhas been delivered in a EMM. It should be noted that there is notnecessarily a one-to-one relationship between each EMM and/or eachservice identifier and each ECM, since service identifiers mayoptionally be used for granting permission to access more than one ECM,and since each ECM may optionally contain more than one such serviceidentifier. Most preferably, each service identifier expires after themulti-cast session has finished, in order to prevent security module 220from being able to grant access to “old” previously transmitted data,although optionally the service identifier could then be renewed andused again for a different such session.

According to an optional but preferred embodiment of the presentinvention, for “pay per view”, an EMM is not necessarily required,although it may optionally be required in order to set those conditionsunder which the purchase may be made, such as possession of a particularnumber of credits by security module 220 for example. Instead, securitymodule 220 would preferably receive a ECM which allows a “free preview”,and/or which contains the necessary information for purchasing thecontent. Such an ECM could optionally and more preferably be labeledwith a “general” or generic service identifier, such that the ECM wouldbe accepted by any security module 220 and/or by security modules 220 ofa particular type of end user device 210. The user could then morepreferably instruct end user device 210 to purchase the content, forexample through security module 220. Optionally and most preferably,credits or other units of exchange for content are kept on securitymodule 220, particularly if security module 220 is implemented with asmart card, in order for the account of the end user to be immediatelyor later debited for the purchased content. Also optionally, an EMMcould be used to deliver credits, tokens or the like, to enable end userdevice 210 to be used to purchase the “pay per view” content.

According to the optional but preferred embodiment of the presentinvention, the content of the EMM is stored securely in the smart cardor other secure portion of security module 220. Thus, the key, orinformation required to generate the key, may optionally be broadcast,while the ability to use such a key is preferably still controlled bybroadcaster 280, through the distribution of some type of permissionmessage for example.

The EMM itself could also optionally be sent to a plurality of differentend user devices 210 at one time, as a broadcast or multicast, such thata group of end user devices 210 would receive the information at once.For example, a particular EMM could be designated for one group of enduser devices 210, according to a particular subscription plan or othertype of payment structure, and/or according to the network address ofthe members of the group of end user devices 210. Alternatively oradditionally, a particular ECM may preferably be blocked for aparticular group of end user devices 210 for a “blackout”. Such ablackout may optionally be implemented for such a group according togeographical location, for example in order to obey laws in a particularcountry, and/or according to characteristics of individual end userswithin the group, for example according to subscription and/or parentalrating information. Preferably, the blackout is determined through ablackout identifier which is contained in the ECM, for identifying anend user device blocked from accessing the content of a particular ECM,such that access may also include the ability to use a control wordand/or information for generating such a control word which is providedthrough the ECM.

Other types of differential access may also optionally be implementedwithin the present invention such that differential access is preferablydefined for different levels of users. For example, such differentialaccess can optionally be determined within the ECM based on serviceidentifiers, where multiple service identifiers apply to onetransmission and are contained in a single ECM, such that a blackoutwould preferably be applied to the services which are not allowed.

For a packet-based network, and particularly for an IP network such asthe Internet, the EMM and ECM information is preferably sent throughchannel 205 according to a particular packet format. End-user client 240would receive a packet for ECM information which would optionally andpreferably contain a header for specifying those service identifiers towhich the packet information would apply, thereby also specifying whichsecurity modules 220 are able to access the ECM information, sincepreferably only those security modules 220 with the correspondingservice identifier would be permitted to access the ECM information.Security module 220 would then compare the specified serviceidentifier(s) to the service identifier information stored by securitymodule 220, and/or within an associated component, such as a smart cardfor example. If the packet is relevant to such a stored serviceidentifier, then security module 220 would read the ECM informationcontained within the packet, in order to be able to access particularmedia content. Such a mechanism would enable ECM information to begenerally transmitted to a plurality of end user devices 210, but onlyto be used by those end user devices 210 for which it is relevant.

More preferably, broadcaster 280 controls the connection between eachECM and the media content to which the ECM provides access. If the useof EMM information/service identifiers is implemented as preferred,broadcaster 280 also preferably controls the connection between eachservice identifier and the ECM information to which the serviceidentifier grants access. Such control enables broadcaster 280 todetermine which end user device 210 receives access to which mediacontent, for example according to payment by the end user, subscriptionbasis and/or other factors, without requiring broadcaster 280 tospecifically transmit a key to each end user device 210 on a one-to-onebasis. Furthermore, since most preferably both ECM information andservice identifiers are renewed periodically, and indeed most preferablymust be renewed periodically, the ability to broadcast or multicast ECMinformation and/or service identifiers to end user devices 210 is evenmore important, since otherwise significant amount of bandwidth forchannel 205 and computational resources would need to be devoted simplyto renewing the access information.

Optionally, broadcaster headend 250 repeatedly transmits the ECM whilethe media content is being received and displayed by end user device210, in order to require security module 220 to repeatedly derive thekey for decrypting or otherwise accessing the media content. Thisrequirement provides additional security, such that if the key or othersecurity information is somehow obtained by an unauthorized user,changing the security information would prevent the unauthorized userfrom accessing all of the media content. Additionally or alternatively,repeatedly transmitting the ECM has the advantage of enabling anauthorized security module 220 to rapidly access the multi-cast content,even if access is initiated in the middle of a multi-cast session. Eachperiod for which the security information is transmitted and/or validmay be termed a “key period”, optionally for validating the ECM. Thelength of the key period may optionally be determined according to alength of time, for example, and/or could be determined by the durationof a particular multi-cast session. Other optional but preferredfeatures of the key period include, but are not limited to, transmittingthe security information, such as the ECM, in advance of the mediacontent; short duration for the key period itself and/or rapid keychange (on the order of seconds between changes); and bufferingpreviously received ECM information and/or previously derived keys, ifsuch information is not changed but only renewed. Both optional featuresprevent access to the media content from being disrupted because thetransmission of the ECM is delayed, which is particularly important forIP networks and other types of networks for which transmission of thepacket is not guaranteed. A corresponding preferred feature of EMMs isan authorization period, such that EMMs are preferably only valid forthe authorization period, after which a new EMM must be received. Thus,the security information is still renewed, while also supporting accessof authorized end users to the media content, even in a non-reliablenetwork environment such as the Internet.

According to a preferred embodiment of the present invention, end userdevice 210 operates a verification module 300 for verifying both thereceived security information from broadcaster headend 250 and theauthenticity of the information contained within security module 220.

Verification module 300 preferably filters all communication external toend user device 210, whether from broadcaster headend 250 or fromanother communication source, in order to determine whether suchcommunication should be passed to security module 220. For example,verification module 300 could optionally have access to identifiers foridentifying particular information which is contained in EMMs, in orderto determine whether security module 220 has access to such EMMs. Suchidentifiers may optionally include, but are not limited to, identifiersfor determining access according to at least one characteristic selectedfrom the group consisting of a characteristic of end user device 210 anda characteristic of information stored on end user device 210.

Verification module 300 would then optionally be able to determinewhether a received packet is relevant to that security module 220,according to the EMM information as previously described. Furthermore,verification module 300 could also optionally and preferably have accessto the service identifiers which are stored in security module 220, inorder to determine whether a particular ECM should be passed to securitymodule 220 for further processing. In addition, more preferablyverification module 300 also determines the authenticity of EMMs and/orECMs, for example by determining whether such messages are digitallysigned for verification.

According to other optional but preferred embodiments of the presentinvention, particularly in implementations containing a plurality ofbroadcaster headends 250, broadcaster headends 250 are distinguishedwith different levels of authorization and/or abilities. For example,some broadcaster headends 250 may only be allowed to transmit contentbased upon the type of service identifier.

In order to ensure compatibility between system 200 and other mechanismsfor IP network security, preferably system 200 is in compliance with theIPSEC (Internet security framework) framework for determining standards,even if the features provided in these standards are not alwayscompletely used. As previously described, security for IP networks iscurrently based upon the IPSEC set of standards, which are intended toprovide a security protocol in the network layer as part of the networkstructure. Optionally and more preferably, one of the announcementprotocols of the IPSEC standards is used in order to associate encryptedor otherwise protected media content with the security information whichis required for access, such as the particular ECM or ECMs for example.For any type of announcement protocol which is used, optionally and morepreferably, the packets associated with such a protocol are encrypted,most preferably with a key which is not session-based but which isavailable and accessible over a longer duration (for example, during aparticular subscription period). One non-limiting example of a standardfor providing such encryption is the SAP (session announcement protocol)protocol of IETF. Alternatively, the announcements may also be deliveredas plaintext, without encryption. However, for certain types ofannouncements, access to the information would preferably and preferablybe restricted, for example only to those end user devices and/orsecurity modules associated with a subscription. Alternatively oradditionally, certain announcements could optionally and preferably bemore freely available, for example in order to deliver generalinformation such as a “free preview mode” for previewing content whichcould then optionally be purchased, which would optionally and morepreferably be available to any end user device having an associatedsmart card (or other general characteristic).

One non-limiting example of a suitable IPSEC announcement protocol isthe SDP (session description protocol), as described in RFC 2327, whichis hereby incorporated by reference as if fully set forth herein. Ofcourse, other types of announcement protocols could also optionally beused, such as CDF (Channel Definition Format) and new XML-basedproposals for example. The protocol is intended to be able to describemultimedia sessions, in which a “session” is a set of multimedia sendingand receiving devices, and the streams of multimedia data which flowfrom sending devices to receiving devices. The description of suchsessions is intended to permit those participants in the session toreceive information about initiating participation, and also about thesession itself. With regard to the present invention, SDP is optionallyand preferably used for conveying information about the protected mediacontent which is transmitted from broadcaster headend 250 to end userdevice 210, and to coordinate between each ECM and the associatedprotected media content.

SDP is a text-based protocol, formatted by lines, in which each line hasthe format type <value>. This information would be contained within apacket as the payload for that packet. The information contained in the<type> field is exactly one character and is case-significant. Theinformation contained in <value> is a structured text string. Theprotocol permits proprietary extensions to the list of various typeswhich are permitted, by using the type a for attribute. Values of type acan optionally be used for the entire session, but alternatively mayonly be used for particular components within the session.

SDP is stated to be usable for transmitting encryption keys forone-to-one key exchange mechanisms. However, the background art does notteach or suggest the use of SDP for transmitting security informationthrough the use of the a or attribute parameter. The present inventionuses the attribute parameter for associating an ECM with the relevantsession and/or a portion of the session, by transmitting the ECM as thevalue for the attribute. In addition, the attribute parameter could alsooptionally be used in order to limit access to different portions of anygiven service, for example based upon payment schemes or authoritylevels. For example, the line containing the ECM information couldoptionally have the format a=ecm:<CASID><IP address <UDP port#> in which“CASID” is an optional parameter for identifying the vendor of theparticular system.

Another IPSEC standard which is optionally and preferably used for thepresent invention is the ESP (IP encapsulating security payload)protocol, as described in RFC 2406, which is hereby incorporated byreference as if fully set forth herein. The ESP format is optionally andpreferably used in order to encapsulate encrypted content and tosynchronize content packets with ECM information. ESP provides a header,containing information about security services, which is intended to beinserted after the IP header and before the upper layer protocol headerfor IP packets being transmitted in the transport mode. According to thestandard, ESP is used to provide confidentiality, data originauthentication, connectionless integrity and limited traffic flowconfidentiality.

The first value in the ESP header is the 32-bit security parametersindex (SPI), which is stated in the standard to be used for uniquelyidentifying the Security Association for the packet, in combination withthe destination IP address and the security protocol. The presentinvention uses the SPI value in order to associate a packet containingencrypted media content with the ECM that is required to generate thekey which encrypted that media content. More preferably, client database260 contains a table for determining this association, such that the SPIis at least part of a set of information for identifying the correct ECMfor the media content, and hence the correct key which is to be used fordecrypting the encrypted media content. Optionally, this set ofinformation also includes the destination IP address, the protocol beingused (such as ESP for example) and the port to which the media contentis sent. The port information is preferred when the securityinformation, such as the ECM, is sent to a particular port of end userdevice 210, for example when multiple vendors may supply end user device210. However, only the SPI is preferably used in order to be able toannounce to security module 220 that the ECM or other securityinformation has been changed when the key period changes. Therefore, arange of SPI values is preferably provided, such that each of change ofSPI value indicates a change to the required ECM, and hence to the keywhich must be generated in order to be able to decrypt the mediacontent.

The background art does not teach or suggest the use of SPI values forindicating the initiation of a new key period, and hence the change ofECM information which is required. However, this implementation isparticularly useful since it enables security module 220 to receive aplurality of different ECMs in advance of their actual use, withoutcompromising the ability of broadcaster headend 250 to still controlaccess by end user device 210. Without the SPI value itself, morepreferably end user device 210 is not able to determine the correct ECMto be used to generate the key, since as previously described, the SPIis at least a part of the set of information which is required fordetermining the correct ECM to be used for decrypting or otherwiseaccessing the media content. Furthermore, the advantage of the SPI overbackground art methods for synchronization, such as using a binary(odd/even) value for synchronizing between the ECM and the mediacontent, is that the SPI can optionally have a large range of values. Ina non-reliable/potentially latent environment such as the Internet,which does not guarantee delivery of packets and which may as a resulthave a large latency period for such delivery, the large range of valueseffectively removes the dependence of each packet from the previouspacket, so that receiving packets out of transmission order and/or evenfailing to receive a packet would not disrupt the security scheme.

According to an exemplary but preferred implementation of the presentinvention, the format of each encrypted media content packet ispreferably as shown in FIG. 4. As shown, an IP header 400 for the packetis followed by the SPI value 410, as determined by the ESP standard aspreviously described. Next, a 32-bit sequence number 420 is included,also as determined by the ESP standard. Sequence number 420 starts atthe value “1” and is monotonically increased for each packet until themaximum value (2³²−1) is reached, at which point the associated SPIvalue 410 is no longer valid and the next SPI value from the range ofpermitted values must be used. In fact, the maximum value may not bereached, since sequence number 420 is preferably reset for each keyperiod when both the security information for the key and SPI 410change.

The next value in the encrypted packet is optionally and more preferablyan initialization vector (IV) 430, which may be required for operatingcertain types of encryption methods such as RC4, for example in order toimprove the strength of the encryption by increasing the randomnessthereof, as is known in the art. The format and length of IV 430 dependupon the particular encryption method.

The packet next features the encrypted media content itself, which isshown as a payload 440 for the packet. Payload 440 may also optionallyinclude such information as the transport layer (UDP or TCP) header.After payload 440, the packet preferably features a PAD length 450 ofone byte, which is always equal to zero. The packet then optionally andpreferably features a next header 460, the value of which preferablydepends upon the type of data which is included after the ESP header, inorder to indicate whether the packet is being transmitted in transportmode or tunnel mode.

FIG. 5 shows an exemplary format for ECM packets, which are preferablyencapsulated as regular clear UDP packets. As shown, the ECM packetfeatures an IP header 500, followed by a UDP header 510. After UDPheader 510, a UDP payload 520 more preferably has two components: an SPI530 for indicating the correct associated SPI value for the ECMinformation, and an ECM information payload 540, which contains theactual ECM information. However, substantially any other suitable formatof packet could be used for transmitting the ECM information, as long asthe ECM information is somehow associated with the correct SPI, so thatend user device 210 is able to determine which ECM should be used withreceived encrypted media content.

Preferably, verification module 300 is able to filter ECM packets inorder to determine which such packets are relevant to security module220 (both not shown; see FIG. 3). Such filtration is optionally and morepreferably performed by comparing previously distributed informationfrom the announcement message about the association between the contentand the combination of the IP multicast, UDP port and SPI values fromthe ECM packet, which are most preferably provided in the header. Mostpreferably, the IP address of the ECM packet is announced with theannouncement message, as previously described, such that security module220 may effectively “filter” the ECM packets by only listening to thoseIP address(es) for ECM packets for which security module 220 has anauthorization, for example from the relevant EMM. Thus, only relevantECM packets are preferably passed to security module 220.

According to other preferred embodiments of the present invention, andas specifically described with regard to FIG. 6, the EMM information,such as the service identifier(s), is transmitted in a packet having aparticular structure. This packet is then more preferably filtered byend-user client 240 and/or verification module 300 (see FIG. 3) in orderto determine if the EMM information is relevant to the particular enduser device 210 before the EMM packet is delivered to security module220 of that end user device 210. Such filtration is preferred in orderto avoid overwhelming security module 220 with a huge amount ofnon-relevant EMM information.

In order to assist end-user client 240 to rapidly filter EMM packets,optionally and more preferably such packets have the structure shown inFIG. 6. As shown, an exemplary EMM packet format is described withregard to implementation as an IP/UDP packet. The packet features an IPheader 600 and a UDP header 610. Next, at least one, and preferably aplurality of EMM 620 are included. Each EMM 620 optionally and morepreferably features a filter type 630, which may be unique, group orgeneral. Filter type 630 determines whether each EMM is allocated to asingle IP address for a particular end user/subscriber (unique), all IPaddresses (general) or a group of IP addresses (group). For both groupand general addresses, the EMM may optionally be sent on a fixedmulticast IP address, which could then be distributed based on regionsin order to optimize EMM delivery performance and client performance.Such a multicast IP address may optionally be configured according toMADCAP (Multicast Address Dynamic Client Allocation Protocol) forexample. Filter type 630 may also optionally and more preferably containinformation related to a particular characteristic or characteristicswhich are stored on security module 220, such as a smart card forexample, and/or are otherwise stored on, or accessible to, end-userclient 240 (both not shown; see FIG. 3). One non-limiting example ofsuch a characteristic would be an identifier for security module 220itself, such as a smart card identifier for example.

Similarly, after each filter type 630, an address 640 containsinformation as to whether the EMM is unique, group or general in type. Alength field 650 is then used, after which an EMM payload 660 containsthe actual EMM information. This packet structure is one example of aformat which may be optionally implemented for greater ease of filteringby end-user client 240.

EMMs may also optionally and alternatively or additionally be sent bye-mail as e-mail messages over the SNMP (simple network messageprotocol) protocol, such that end-user client 240 and/or end user device210 could then optionally retrieve the EMMs as e-mail messages, forexample at the initialization of operation of end user device 210 foreach session.

FIG. 7 shows a schematic block diagram of a preferred embodiment ofbroadcaster headend 250. As shown, broadcaster headend 250 optionallyand preferably features a plurality of components for performingencryption of the media content, and for synchronizing transmission ofencrypted or otherwise protected media content and the correspondingsecurity information and/or access schemes for determining access to theprotected media content. A traffic system 700 receives information aboutthe media content, metadata and schedules of new IP sessions. Trafficsystem 700 also preferably ensures that sufficient bandwidth isavailable on channel 205 (not shown) and/or within broadcaster headend250 before scheduling IP sessions. In addition, traffic system 700optionally and more preferably determines if the media content is withinan authorized size range. If sufficient bandwidth is available and/or ifother criteria are met, then traffic system 700 preferably generates theappropriate access criteria for being included in the ECM, andconfigures the system-wide security association parameters, which arerequired for enabling end user device 210 to eventually obtain access tothe protected media content. Examples of access criteria include but arenot limited to, price (particularly for the previously describedpay-per-view system), parental rating and “blackout” criteria, which arecriteria for determining whether a particular end user device 210 maynot be granted access to the associated content. Traffic system 700 mayoptionally be implemented as a traditional television traffic system ordata content provider system. In the latter type of system, the contentprovider has remote access to the system in order to define and schedulemulticast sessions asynchronously as desired.

Once traffic system 700 has scheduled the new IP session, with theappropriate security parameters, information about the IP session ispreferably passed to a transmission server 710. Transmission server 710preferably announces each IP session and transmits the content to theappropriate IP address and UDP port of end user device 210 according tothe schedule which is determined by traffic system 700. The mediacontent and associate security information is then preferably passed toan IPSEC encryption system 720 for encryption and packaging into packets(“packetization”) as described in greater detail below.

Transmission server 710 itself optionally and more preferably alsofeatures a separate announcement server 725 for creating andtransmitting announcement messages, for example according to the SDPstandard as previously described. Announcement server 725 preferablyreceives information from traffic system 700 concerning the schedule forthe IP session, addresses of content and an ECM address pair (IP addressand client port address), as well as the identifier for the ECM itself.The announcement message preferably includes all of these differenttypes of information, and is preferably transmitted on a well known portaddress, although the session itself may optionally be conducted ondifferent client ports. The address for the announcement may itselfoptionally be transmitted to each end user device 210 (not shown)automatically through standard digital video broadcast (DVB) streamssuch as the program specific information (PSI) and/or programmingmapping table (PMT) streams, or the service information (SI) or servicedefinition table (SDT) streams.

Turning back to traffic system 700, the information concerning the mediacontent to be transmitted, the identity of the recipient end userdevices 210, optionally subscriber information and other types ofinformation are preferably sent from an external management server 730,which manages and configures separate network entities. Examples of suchentities include, but are not limited to, subscribers, addresses, accesscriteria and bandwidth. External management server 730 also passes thenecessary information to, and manages the activities of, a contentencryption server 740, which may optionally operate according to anystandard encryption method, including but not limited to, AES (advancedencryption standard), and DES.

Content encryption server 740 is also optionally and preferably incommunication with a synchronization system 750. Synchronization system750 preferably synchronizes the transmission of announcement messages,media content and ECMs, after receiving information about the IPsessions from traffic system 700. The transmission of EMMs is notnecessarily synchronized with the transmission of these other messages,as long as the service identifier(s) are transmitted in a timely mannerbefore the ECM is to be received and/or used. Furthermore, an EMM is notnecessarily transmitted at all, such as for the optional “pay per view”mechanism, which as previously described does not require EMMs foroperation. Synchronization system 750 also more preferably assigns allsystem addresses, including IP and port addresses.

Once the session has been scheduled, the security information has beenselected (including at least one ECM for encrypting the media content),and the content has been synchronized with the security information,content encryption server 740 then encrypts the actual media contentitself More preferably, the media content is encrypted with the keywhich would be generated from the ECM, as received by the end userdevice (not shown; see FIG. 3). Optionally and most preferably, contentencryption server 740 contains an ECM generator 745 for generating thesecurity information. ECM generator 745 generates a control word foractually encrypting the media content.

The same control word must then be generated again at the end userdevice (not shown) in order for the media content to be accessed anddisplayed. The ECM itself must also be generated from at least thecontrol word, and more preferably also from access criteria, concerningthose end user devices (not shown) which are allowed to have access tothe media content. However, the present invention is not limited to thistype of mechanism, but may also include implementations in which ECMgenerator 745 does not generate the control word, which is insteadgenerated separately by a separate control word generating module (notshown). For the latter type of implementation, preferably ECM generator745 generates the ECM from a combination of the control word and accessinformation.

Next, ECM generator 745 preferably schedules transmission of thecorresponding ECM and transmits the ECM when ready. Also, ECM generator745 optionally and preferably inserts the SPI within the packetcontaining the ECM information, as previously described. If the SPI isused, then ECM generator 745 also optionally and preferably incrementsthe SPI counter at each key period change, also as previously described.

A corresponding service identifier is preferably determined (as one typeof access criteria) for association with an ECM, in order to be able toinform the end user devices as to whether they are authorized to use theECM. The EMM information (service identifier) is preferably placed in aEMM by a separate EMM generator 755. The EMM information is optionallysent on a fixed multicast IP address and port to the end user devices.

The encrypted content is then passed to an IPSEC management system 760,which manages the process of forming packets and including the IPSECencryption information at IPSEC encryption system 720. IPSEC managementsystem 760 more preferably manages the security policy database and thesecurity association database based upon input received fromsynchronization system 750 and content encryption server 740. IPSECmanagement system 760 optionally and preferably stores information inthe security association database concerning the type of encapsulationprotocol for creating the packets, such as ESP for example as previouslydescribed; the type of encryption method which is used for encryptingthe actual media content, such as RC4, DES or 3DES, for example; thetype of IP mode for transmitting the packet, such as transport mode forexample; and information about the initialization vector (IV) if in factone such vector exists.

IPSEC management system 760 also preferably merges the control word,security association parameters and SPI information with IP multiplexinginformation.

IPSEC encryption system 720 preferably performs two functions:encryption according to the IPSEC standards, and packet formation. Thepackets are formed by receiving the incoming encrypted content andassociated information, according to the IPSEC standards as previouslydescribed. More preferably, the packets are formed by adding the ESPheader with the appropriate SPI to the encrypted content, after whichthe packets are transmitted. Optionally and more preferably, packetscontaining security information such as ECMs and EMMs, and alsoannouncement messages, are forwarded for distribution through the IPnetwork without being transformed into packets by IPSEC encryptionsystem 720. IPSEC encryption system 720 then performs encryption of thepacket contents as required.

According to optional but preferred embodiments of the presentinvention, the previously described management and encryption system maybe optionally implemented with Simulcrypt protocols. These protocolsenable an IPSEC-enabled encryptor, such as IPSEC encryption system 720for example, to encrypt the IP content (streams or files) once based ona unique key (or control word) generated by a local key generator. Thiskey may then optionally be sent over standard Simulcrypt protocols tomultiple separate ECM generators of separate CA (content access) systemsto enable secure ECM delivery across these different content accesssystems. In other words, with one encrypted content stream and/or fileand one key or control word, multiple ECMs may be possible.

FIG. 8 shows an exemplary but preferred implementation of end-userclient 240 in greater detail. As shown, end-user client 240 preferablyfeatures an IPSEC decryption system 800 for receiving all packet data,which is preferably IP data, and also for decrypting such data ifnecessary. IPSEC decryption system 800 is preferably able to retrievethe necessary SPI and other security related information, in order todecrypt the packet data.

The decrypted data is then passed to an application 810 which hasrequested this data. Each application 810 preferably acts as a triggerfor receiving more data, by opening a socket and receiving content fromIPSEC decryption system 800.

IPSEC decryption system 800 also preferably communicates with an IPSECmanagement system 820 for implementing the security policy database andsecurity association database, for storing the necessary securityinformation. Such information is optionally stored in client database260 (not shown; see FIG. 3). IPSEC management system 820 preferablymanages EMM information and other security information as well,including, but not limited to, source IP and source port addresses;destination IP and port addresses; SPI, control word and IP multiplexinginformation. IP multiplexing information may include such information asthe type of encryption algorithm, initialization vector, transport ortunnel mode, and so forth. All of these components are preferably incommunication with security module 220 and/or verification module 300(not shown; see FIG. 3). Optionally, IPSEC management system 820 alsomanages the functions of security module 220 as well.

One optional embodiment for the present invention involves membershiprevocation for an end user device which has left a group, involvingrevocation of authorization for service identifiers and/or limiting thekey period for the service identifiers. The remaining group members thenrequire reauthorization, although with short key periods, suchreauthorization would be frequently performed without a specialprocedure. It is even possible to make a reauthorization necessarywithin a multi-cast session. The local security module could optionallyprevent access to the service identifiers and/or other authorizationinformation. As an example, a system of rules for this usage of serviceidentifiers is optionally and preferably determined at the broadcasterheadend, and then transmitted to the smartcard (security module).Revocation is optionally performed by sending information with an EMM,although alternatively or additionally, revocation is preferablyperformed with an ECM. For example, revocation is optionally performedby sending an EMM hidden within an ECM, thereby causing the smart cardor other local security module to obtain or lose authorization,according to the desired outcome.

The method of the present invention also avoids another major loopholeand problem for multicast security, with regard to key sharingconspiracies. In the standard model in the background art, the keys canbe shared quite easily, since they tend to last a long time. In thepresent invention, the keys (control words) are preferably changed veryoften according to a relatively short key period, so sharing is moredifficult, certainly for streaming data. This solution also prevents thereuse of old keys and/or old content, since any current key is thenpreferably unable to decrypt previous or future transmissions ofcontent. Standard models for multicast in the background art do not dealwith this problem efficiently.

The previous discussion has clearly demonstrated the utility of thepresent invention in a broadcaster-controlled network environment, inwhich one broadcaster transmits data to a plurality of end user devicessimultaneously through a network, particularly a packet-based network ina non-reliable environment or at least an environment in whichreliability is not guaranteed, such as the Internet or other IP network.Other security mechanisms have been developed for such networkenvironments, but they have not been shown to be useful for broadcastdata, as they are concerned with security for a session between twoparties.

As an example, the SSL (secure sockets layer) protocol may beconsidered. SSL is clearly only useful for secure, reliablecommunication between two hosts through a network, unlike the presentinvention, such that SSL is not only not intended for multicasting, butin fact is not usable for multicasting. SSL also relies upon a trustedcertificate authority; once both parties have received suchcertificates, they mutually trust each other completely. By contrast,the present invention requires continuous or at least repeatedauthentication of the end user device, thereby preventing anunauthorized user from gaining initial access and then continuing toreceive services from the broadcaster. Also, SSL only supports theTCP/IP connection protocol, but does not operate over the UDPconnectionless protocol, while the method of the present invention workswith both the connection and connectionless protocols. Thus, SSL is notscalable to a large number of end user devices, while the presentinvention is scalable to such a large number of end user devices.

According to another preferred embodiment of the present invention,there is provided a mechanism for transferring content through a“peer-to-peer” system. The term “peer-to-peer” refers to the transfer ofdata, such as the content and/or associated security information,between end user devices. This preferred embodiment may be used toreduce the load on the central server or other central authorizationentity.

There are various scenarios that are possible in order to managepeer-to-peer sessions. The simplest model preferably features a securityserver at each peer end user device. The security server couldoptionally be implemented with any platform which is capable of securestorage and secret cryptographic calculations, whether in protectedhardware or software. One non-limiting example of such a platform is asmart card with a smart card reader. Each such security server would becapable of all the procedures previously described as occurring in thehost, at the broadcaster/broadcaster headend in FIG. 3, for example.Each host can optionally and preferably generate its own list of serviceidentifiers and Control Words or another type of key to be used toauthorize any other peer end user device (or set of hosts), and toencrypt communications.

Authorizations are more preferably performed with locally generated EMMssigned by the local security server, while data is more preferablyencrypted by the local security server. SDP announcements would begenerated locally and digitally signed to authenticate the session call.One potential drawback of this mechanism is the significant potentialfor collisions for all elements, particularly with regard to serviceidentifiers. Therefore, as a preferred feature, for all sessions with amembership group of peer devices, each local host would optionally andpreferably coordinate through a central host, a Group Controller. Thiscoordination could optionally occur in advance of a specific session;for example, each new local host which becomes a member is then assigneda range of service identifiers, for example. Alternatively, thiscoordination could optionally be performed through the packet-basednetwork in “real time”, such that before or at the start of eachsession, the local host would request an identifier from the GroupController (GC). This GC is preferably not a classic Group Controller asdefined in the discussions above, but would have a very limited functionof coordination, with minimal overhead.

Once recourse is made to Group Controller involvement in peer to peerinteractions, a model may optionally and more preferably be implementedin which the Group Controller plays an even more significant role in thepeer to peer session. In addition to the coordination and assignment ofservice identifiers, the Group Controller may also optionally scheduleall synchronization requirements for the system including announcementsand access criteria generation. Optionally and most preferably, the GCgenerates the ECMs to be transmitted, while locally generating the CW(control word; used for local creation of the control word as previouslydescribed).

For local hosts that are very limited in terms of computational powerand/or bandwidth, the model is optionally altered to enable all elementsto be generated and/or coordinated by the GC including data encryptionand CW generation, apart from the setup parameters, which are defined bythe local hosts.

An intermediate version of the above model preferably features a generalbroadcaster headend (as for FIG. 3, for example) to register a sessionand to generate a steady flow of CW to encrypt and decrypt peer to peersessions. Such a model may be preferably implemented if the localheadend is not considered secure enough to have a CW generator on-site,particularly in cases where the CW generator is implemented in software.For this model, each EMM carrying service identifiers is supplied by thecentral, general headend upon registration, but alternatively may begenerated by each peer for another peer.

Any suitable combination of the above features is considered to bewithin the scope of the present invention, and may optionally beimplemented as practicable depending upon the needs of the specificsession, and the capabilities of the hosts.

An additional, optional configuration of the peer to peer model would bea variation on the tree model of distribution (and authentication) byusing a cluster model. The cluster would preferably have specialattributes, where any given peer would reside in a cluster, and aspecific topology of other peers would be established for each session(like a flat tree model), such that any change to that topology wouldaffect some change in either authentication or distribution. Forexample, other peer devices would optionally and preferably be allowedto introduce new peer devices to the topology. This model could beeffective in supporting various superdistribution models, for examplewhere there are business rules that allow the redistribution of contentfrom receivers of that content, under certain specified conditions.

Such a model could optionally be specifically implemented according tothe preferred embodiments of the present invention by enabling a localpeer device, which has been authorized by an EMM for a specific serviceidentifier, to send a new EMM for authorizing another host for thatservice identifier. If tighter control is desired, then another serviceidentifier is most preferably required, which would then be reportedback to the originating service provider (such as the broadcaster ofFIG. 3, for example), which is an example of a central authorizationentity. The central authorization entity preferably at least coordinatesthe cluster, and more preferably continuously validates the cluster.

Once the new service identifier is received, the provider could then addthis service identifier to the list that becomes included in the ECM fordecryption access. This avoids passing control of the new peer devicefrom the interested peer device to a central authorizing authority,without involving any need to decrypt and re-encrypt at the local hostlevel.

Based on the previous model, local clusters of peer devices couldoptionally generate specific groups of requests to the central serverwhich then arbitrates sessions to other clusters of such peer devices.

Alternatively or additionally, the local peer device is preferably ableto receive an ECM, use the control word to encrypt local content(through the security module such as the smart card) and then transmitsuch encrypted content to other peer devices. Alternatively, if the peerdevice is not able to perform encryption locally, or if the data is suchthat it does not require encryption, the generated control word couldoptionally still be used as a basis (or seed) for a hashed signaturescheme, for example by using the smart card for generating thesignature.

However, the requirement for a certain level of computational ability ofthe peer device is a feature of these preferred embodiments. Forexample, if the peer devices are required to generate announcements,such as SPI messages, and/or EMMs, as well as to deliver content, acertain amount of buffer space is required to store all incoming CWs andSPI messages for decrypting. The generation of ECMs is most preferablykept at a central ECM generator, both for security reasons and to reducethe computational load on the peer devices.

Optionally and more preferably, peer devices are distinguished withdifferent levels of authorization and/or abilities. For example, somepeer devices can view and write to all other devices, while some suchdevices can only view or write to certain devices, etc. Optionally, somepeer devices may only be allowed to transmit content based upon the typeof service identifier.

According to other optional but preferred embodiments of the presentinvention, EMMs are delivered out of band (that is, separately from thecontent). For example, EMMs could optionally and preferably be deliveredthrough encrypted (or open) e-mail messages. Using IETF standards suchas Privacy Enhanced Mail (PEM) or MME Object Security Services, ornon-IETF PGP (Pretty Good Privacy). Unfortunately, delivery by e-mailmessages again raises the issue of scalability. If the email messageshould be secured, then finding and using public keys is a problem. Suchkeys could optionally be cached locally or obtained from a publicdirectory, although this may cause the processing overhead to becomevery high with a very slow distribution. Thus, preferably this mechanismis not used for key distribution, but only for EMM distribution, whichcould optionally be performed without encryption, such that onlyauthentication signatures are preferably required, as a replacement fore-mail message invitations to multi-cast sessions.

According to other optional embodiments of the present invention,particularly with regard to peer-to-peer distribution of content,content is authenticated by authenticating the source. For example, asignature or other secret information could optionally be added for thispurpose, such as an identifier for the source device (such as the sourcesecurity module), and/or a public key signature. Preferably, however,the signature or other secret information is used as a seed to a simplehash function, which then enables the end user device to rapidlyauthenticate the source of the information.

While the invention has been described with respect to a limited numberof embodiments, it will be appreciated that many variations,modifications and other applications of the invention may be made.

1. A method for securely multicasting media content to a plurality ofend user devices without requiring one-to-one key exchange the methodcomprising: encrypting at least part of the media content with a key toform encrypted packets, the key being at least partially generable fromkey generation information, the key generation information and the keybeing changed according to a key period; multicasting the key generationinformation to the end user devices through an Internet Protocolpacket-based network, the key generation information including firstaddress information; multicasting the encrypted packets to the end userdevices through the Internet Protocol packet-based network, theencrypted packets including second address information; creating anannouncement including the second address information of the encryptedpackets and the first address information of the key generationinformation; and transmitting the announcement to the end user deviceswherein the end-user devices are operative to matching between theencrypted packets and the key generation information based on the firstand second address information included in the announcement, wherein thetransmitting and the multicasting takes place in the Internet Protocolpacket-based network, the Internet Protocol packet-based network beingsecured according to an Internet protocol security standard, theannouncement being created and transmitted according to an announcementprotocol of the Internet protocol security standard.
 2. The method ofclaim 1, wherein said key generation information includes control wordinformation for key generation at each end user device.
 3. The method ofclaim 2, wherein an ECM (entitlement control message) is sent to saidend user devices for said key generation information for said keygeneration, such that said ECM contains said control word informationfor said key generation.
 4. The method of claim 3, wherein said ECM ismulti-cast to said end user devices, and wherein an EMM (entitlementcontrol message) is also transmitted to said end user devices, such thatEMM information contained in said EMM is required for said end userdevice to access said ECM.
 5. The method of claim 4, wherein said EMM istransmitted to said end user devices by an out-of-band message, suchthat said EMM is not transmitted with said encrypted packets.
 6. Themethod of claim 5, wherein said out-of-band message is an e-mail(electronic mail) message.
 7. The method of claim 4, wherein said ECM istransmitted through said IP network according to at least one of amulticast IP address and an IP port, such that said end user device isnotified of said at least one of said multicast IP address and said IPport through the announcement protocol.
 8. The method of claim 4,wherein said end user device filters at least one of said ECM and saidEMM according to at least one characteristic selected from the groupconsisting of a characteristic of said end user device and acharacteristic of information stored by said end user device.
 9. Themethod of claim 8, wherein said end user device filters said ECMaccording to EMM information, such that only an ECM for which EMMinformation has been received is accessed by said end user device. 10.The method of claim 9, wherein said ECM is contained in a packet, and anIP address for said packet is announced to said end user device, suchthat said end user device filters said ECM by listening to said IPaddress for receiving said packet if said end user device has receivedsaid EMM information.
 11. The method of claim 8, wherein said end userdevice filters at least one of said ECM and said EMM according towhether said at least one of said ECM and said EMM is designated asunique, group or general.
 12. The method of claim 4, wherein said EMMinformation includes a service identifier, and wherein said serviceidentifier is related to a type of content of said encrypted packets.13. The method of claim 12, wherein said encrypted packets contain aplurality of different types of content, each type of content having aseparate service identifier, such that differential access to saiddifferent types of content by said end user device is provided accordingto said service identifiers.
 14. The method of claim 12, wherein saidservice identifier corresponds to a plurality of ECMs.
 15. The method ofclaim 4, wherein said EMM information includes an identifier fordetermining access to said encrypted packets according to at least onecharacteristic selected from the group consisting of a characteristic ofan end user device and a characteristic of information stored on saidend user device.
 16. The method of claim 15, wherein said identifier isa blackout identifier for identifying an end user device blocked fromaccessing a content of said ECM.
 17. The method of claim 16, whereinsaid blackout identifier corresponds to at least one characteristicstored in said end user device.
 18. The method of claim 17, wherein saidat least one characteristic includes a geographical location of said enduser device.
 19. The method of claim 4, wherein said ECM enablesdifferential access to said encrypted packets by said end user deviceaccording to a plurality of identifiers transmitted in said EMM.
 20. Themethod of claim 4, wherein said end user device stores at least acontent of at least one of said ECM and said EMM.
 21. The method ofclaim 20, wherein said ECM has a limited key period, such that a new ECMis periodically received to access said encrypted packets.
 22. Themethod of claim 21, wherein a length of said key period is at leastpartially determined by a length of a session for receiving saidencrypted packets by said end user device.
 23. The method of claim 22,wherein said length of said key period is less than said length of saidsession, such that at least one of a new ECM and a new EMM must bereceived repeatedly during said session.
 24. The method of claim 23,wherein said EMM has a limited authorization period, such that a new EMMis periodically received to access said encrypted packets.
 25. Themethod of claim 3, wherein at least a portion of said encrypted packetsare accessible with said ECM only, without said EMM, as a preview ofsaid encrypted packets.
 26. The method of claim 4, wherein said packetsare transmitted as part of a multi-cast session, and wherein anannouncement for said session is transmitted according to theannouncement protocol.
 27. The method of claim 4, wherein said standardIP protocol is IPSEC.
 28. The method of claim 27, wherein saidannouncement includes information for relating each ECM to a serviceidentifier contained in an EMM.
 29. The method of claim 28, wherein saidannouncement protocol is SDP (session description protocol).
 30. Themethod of claim 28, wherein said ECM is associated with at least aportion of a multi-cast session with said end user device, and whereinsaid association is transmitted in said encrypted packets as anattribute parameter.
 31. The method of claim 30, wherein said ECM issynchronized with said encrypted packets with an SPI (securityparameters index) value of said encrypted packets.
 32. The method ofclaim 31, wherein a new key period is indicated by a change in said SPIvalue, such that a new ECM is required to access said encrypted packets.33. The method of claim 26, wherein the announcement is encrypted. 34.The method of claim 15, wherein said end user device is blocked fromfurther access to said encrypted packets through revocation with atleast one of an EMM and an ECM.
 35. The method of claim 34, wherein saidrevocation is for a specific end user device.
 36. The method of claim35, wherein said revocation is for a plurality of end user devices. 37.The method of claim 34, wherein said revocation causes a new serviceidentifier to be required for accessing a content of an ECMcorresponding to said encrypted packets.
 38. The method of claim 4,wherein said end user devices receive at least said encrypted packetsfrom at least one peer end user device.
 39. The method of claim 38,wherein said at least one peer end user device generates at least one ofsaid EMM and said ECM.
 40. The method of claim 39, wherein said at leastone peer end user device includes a secure server for generating saidleast one of said EMM and said ECM.
 41. The method of claim 39, whereinsaid EMM generated by said at least one peer end user device isauthenticated by a central authorization entity.
 42. The method of claim39, wherein said EMM generated by said at least one peer end user deviceis mapped to a new ECM for accessing said encrypted packets by a centralauthorization entity.
 43. The method of claim 39, wherein said packetsare transmitted as part of a multi-cast session, an announcement forsaid session is transmitted according to the announcement protocol, andsaid announcement includes at least an SPI (security parameters index)for relating each ECM to a service identifier contained in an EMM, suchthat said at least one peer end user device generates at least one ofsaid announcement and said SPI.
 44. The method of claim 32, wherein saidcentral authorization entity controls at least one of said ECM, saidEMM, said announcement and said SPI.
 45. The method of claim 32, whereinat least one of said EMM and said ECM is generated by said centralauthorization entity.
 46. The method of claim 32, wherein said end userdevices are located in a cluster, and wherein each cluster iscoordinated by said central authorization entity.
 47. The method ofclaim 46, wherein said cluster is continuously validated by said centralauthorization entity.
 48. The method of claim 3, wherein a pay-per-viewECM contains purchasing information for purchasing access to saidencrypted packets and wherein EMM information is not required to accesssaid pay-per-view ECM.
 49. The method of claim 3, wherein an EMMcontains a credit for purchasing access to said encrypted packets forpay-per-view content.
 50. The method of claim 28, wherein saidannouncement protocol is SAP (session announcement protocol) of IETF.51. The method of claim 28, wherein said announcement protocol is CDF(Channel Definition Format).
 52. The method of claim 28, wherein saidannouncement protocol is an XML based announcement protocol.
 53. Themethod of claim 28, wherein said announcement protocol is ESP protocol.54. The method according to claim 1, wherein a change of the key periodis announced by an SPI (security parameters index) in a securityinformation message according to ESP (IP encapsulating security payload)protocol.
 55. A method for securely receiving media content at an enduser device without requiring one-to-one key exchange, the methodcomprising: receiving key generation information in an end user devicethrough an Internet Protocol packet-based network, at least some of thekey generation information including first address information, the keygeneration information being changed according to a key period;receiving a plurality of encrypted packets in the end user devicethrough the Internet Protocol packet-based network, at least some of theencrypted packets including second address information; receiving anannouncement in the end user device, the announcement including thesecond address information of the at least some encrypted packets andthe first address information of the at least some key generationinformation; matching between the at least some encrypted packets andthe at least some key generation information based on the first andsecond address information included in the announcement, wherein thereceiving takes place via the Internet Protocol packet-based network,the Internet Protocol packet-based network being secured according to anInternet protocol security standard, the announcement being created andtransmitted according to an announcement protocol of the Internetprotocol security standard.
 56. The method of claim 55, wherein an ECM(entitlement control message) is received at the end user device, theECM including the control word information.
 57. The method of claim 56,wherein an EMM (entitlement control message) is received at the end userdevice, such that EMM information contained in the EMM is required forthe end user device to access the ECM.
 58. The method of claim 57,wherein the ECM is received via the IP network according to at least oneof a multicast IP address and an IP port, such that the end user deviceis notified of the at least one of the multicast IP address and the IPport through the announcement protocol.
 59. The method of claim 57,wherein the standard IP protocol is IPSEC.
 60. The method of claim 59,wherein the announcement includes information for relating each ECM to aservice identifier contained in an EMM.
 61. The method of claim 60,wherein the announcement protocol is SDP (session description protocol).62. The method of claim 60, wherein the ECM is associated with at leasta portion of a multi-cast session with the end user device, and whereinthe association is transmitted in the encrypted packets as an attributeparameter.
 63. The method of claim 62, wherein the ECM is synchronizedwith the encrypted packets with an SPI (security parameters index) valueof the encrypted packets.
 64. The method of claim 63, wherein a new keyperiod is indicated by a change in the SPI value, such that a new ECM isrequired to access the encrypted packets.
 65. The method of claim 55,further comprising generating a key based on the at least some keygeneration information.
 66. The method of claim 55, further comprisingdecrypting the at least some encrypted packets with the key.